HSDPA is a feature that was introduced in Release 5 of the third generation partnership project (3GPP) specifications in order to increase data rates in the downlink for packet data users. Downlink data is transmitted by a Node-B to a wireless transmit/receive unit (WTRU) via a high speed downlink shared channel (HS-DSCH). The WTRU sends feedback to the Node-B via a high speed dedicated control channel (HS-DPCCH).
Adaptive modulation and coding (AMC), hybrid automatic repeat request (H-ARQ) and fast Node-B scheduling are some of the new features in HSDPA. AMC adapts the transmission date rate on the HS-DSCH according to the channel conditions perceived by the WTRU. The Node-B determines the best rate and scheduling for individual transmissions using the following information:
(1) a channel quality indicator (CQI) reported from a WTRU, which indicates the quality of the channel that is perceived by the WTRU;
(2) a transmit power control (TPC) command of associated dedicated channels; and
(3) positive acknowledgement (ACK)/negative acknowledgement (NACK) feedback in response to previous HS-DSCH transmissions.
Lower data rates are generally used for transmissions to WTRUs perceiving unfavorable channel conditions, (e.g., at cell-edge), resulting in smaller transport blocks per 2 ms transmission time interval (TTI). Higher data rates are used for transmissions to WTRUs perceiving favorable channel conditions, resulting in higher transport blocks per 2 ms TTI.
The WTRU reports the CQI over the HS-DPCCH, which provides to the Node-B an indication of the quality of the channel that is perceived by the WTRU in the downlink. The CQI indicates the highest MAC-hs transport block size that the WTRU may receive in the downlink within the 2 ms TTI, for which the transport block error probability is less than 0.1, (i.e., 10%). The mapping between CQI and transport block size for Category 10 WTRU is shown in Table 1. Different CQI lookup tables are provided for each WTRU category. A higher CQI value corresponds to a higher transport block size.
TABLE 1Trans-portNumber CQI Block ofModu-valueSizeHS-lation11371QPSK21731QPSK32331QPSK43171QPSK53771QPSK64611QPSK76502QPSK87922QPSK99312QPSK1012623QPSK1114833QPSK1217423QPSK1322794QPSK1425834QPSK1533195QPSK163565516-QAM174189516-QAM184664516-QAM195287516-QAM205887516-QAM216554516-QAM227168516-QAM239719716-QAM2411418816-QAM25144111016-QAM26172371216-QAM27217541516-QAM28233701516-QAM29242221516-QAM30255581516-QAM
An important application for HSDPA is the transmission of Voice over IP (VoIP) traffic. VoIP is an emerging technology for the transport of speech over packet-switched networks. VoIP significantly differs from non real-time data-oriented applications in terms of quality of service (QoS), as end-to-end delay is the strictest requirement.
FIG. 1 shows protocol architecture for transmission of VoIP in universal mobile telecommunication system (UMTS). The speech signal is encoded by a voice codec in frames of 20 ms duration. The encoded voice signal is then carried over real-time transmit protocol (RTP), user datagram protocol (UDP) and Internet protocol (IP). These are commonly accepted protocols for the transportation of voice traffic over packet-switched networks.
FIG. 2 shows a conventional VoIP packet. The VoIP packet that is transmitted over the radio network may measure 72 or 92 bytes in size, depending on the IP version, (i.e., IPv4 or IPv6). Referring again to FIG. 1, the VoIP packets are delivered to the packet data convergence protocol (PDCP) layer, which compresses the RTP, UDP and IP headers for transmission over the air interface. The PDCP layer uses robust header compression (ROHC). A number of states may be defined for ROHC throughout the life of a single VoIP call. In one state, a full frame without any compression may be delivered to lower layers for transmission. In another state, full compression of RTP/UPD/IP headers down to ˜1 byte may take place. This results in variable packet sizes, ranging from 33 bytes to 92 bytes.
The compressed PDCP layer packets are then delivered to a radio link control (RLC) layer. The RLC layer typically operates in an unacknowledged mode (UM) for VoIP packets. The RLC layer appends an additional one (1) byte header to the PDCP layer packets. The RLC protocol data units (PDUs) that are delivered to a medium access control (MAC) layer have sizes ranging from 34 bytes (full header compression with IPv4) to 93 bytes (no header compression). The MAC layer includes one or more RLC PDUs (each RLC PDU corresponding to a VoIP packet) in a single transport block for transmission.
The WTRU reports perceived downlink channel quality by sending a CQI to the Node-B. The CQI indicates the maximum transport block size that the WTRU may receive with a 10% probability of packet error. Low CQI values are reported to the Node-B in bad channel conditions, corresponding to smaller transport block sizes. In some cases, the next packet to be transmitted to the WTRU may be larger than the maximum transport block size specified via the CQI. Considering the VoIP service as an example, where RLC PDUs range from 272 bits (34 bytes) to 736 bits (92 bytes) in size, according to Table 1, CQI values 1, 2 and 3 suggest transport blocks that are too small for the 272-bit RLC PDU. Similarly, CQI values 1 through 7 suggest transport block sizes which are too small for the largest RLC PDU, (i.e., 736 bits).
The Node-B may react in two different ways when the CQI indicates a block size that is smaller than the next packet in queue. The Node-B may wait until the channel conditions improve and the WTRU indicates that the WTRU is able to receive the MAC-hs PDU with reasonable error probability. Alternatively, the Node-B may transmit a larger transport block size than is indicated by the CQI and rely on the H-ARQ process for successful delivery of the packet.
In the first approach, the Node-B does not schedule any transmission to the WTRU until the Node-B receives a CQI large enough to transmit the next packet in queue. This can take an extended amount of time as larger CQI reports will only be reported once channel conditions improve. This approach might be suitable for non real-time applications, which can tolerate variable delays, but unacceptable for delay sensitive applications such as VoIP.
In the second approach, the Node-B schedules the transmission of the VoIP packet regardless of the poor CQI. The transmission will likely fail because of the larger transport block than can be received with 10% error probability. A successful transmission should eventually occur after a certain number of retransmissions via H-ARQ mechanism. However, the H-ARQ retransmissions introduce undesirable delays for real-time applications. Conventional HSDPA systems do not effectively transfer real-time traffic, especially for users perceiving poor channel conditions.